The use of wireless networks as a communication medium for transferring data has continued to increase as mobile device functionality has improved and wireless network standards have put further emphasis on service related quality. For example, Long Term Evolution (LTE) sets forth standards that provide for increased capacity and link speeds as compared with other communication technologies, and provide specific quality standards for voice and data traffic. In particular, LTE defines Random Access Channel (RACH) procedures that define and control the interaction between a mobile device and a respective eNodeB, i.e., base station, over an access channel.
In particular, a mobile device may initiate RACH procedures for establishing an uplink/download link for data communications. RACH procedures may be used for random access transmission and/or transport of control information. For example, RACH procedures may be initiated to register a mobile device with an eNodeB after mobile device power up, location registration and to initiate services such as placing a call from the mobile device. The RACH procedure may be initiated by transmission of a Random Access (RA) preamble message to the eNodeB. The RA preamble message may include the preamble ID such as a random number chosen from a group of random numbers. In response to receiving the RA preamble message, eNodeB may transmit a RA response (RAR) message including at least one preamble ID, timing alignment information and initial uplink grant, among other data. Receiving the RAR message at the mobile device indicates the end of the RACH procedure, i.e., the RACH procedure was successful, and the beginning of the radio resource control (RRC) connection request procedure. In response, to receiving the RAR message, the mobile device may transmit a RRC connection request message to the eNodeB. For example, the RRC connection request message may be transmitted to the eNodeB via the Physical Downlink Shared Channel (PDSCH) according to the information contained in the RAR message, i.e., uses specific resources and timing information in the RAR message. The RRC connection request message may include mobile device identity and other information. In response to a received RRC connection request, the eNodeB may transmit an RRC connection setup message indicating that mobile device may commence data transfer via the eNodeB, i.e., mobile device is now in an RRC_connected state.
However, problems occur during the RACH procedure and/or during the RRC connection request procedure such as to cause a mobile device to reinitiate the RACH procedure. In particular, several problems may occur during the initiating of the RACH procedure. For example, the RA preamble message may be dropped by the eNodeB due to a Cyclic Redundancy Check (CRC) error or CRC failure. In particular, a CRC error could occur if too many RA preamble messages arrive within the transmission time interval (TTI). Moreover, RA preamble messages may be dropped by the eNodeB when the message rate on the access channel reaches the maximum capacity. Upon determining that the RA preamble messages have been dropped, mobile device may reinitiate the RACH procedure, i.e., retransmit the RA preamble message. If the problem that caused the RA preamble to be dropped still exists, the re-initiation of the RACH procedure may add to the problem, i.e., the eNodeB is already at maximum capacity. Even if the eNodeB receives and processes the RA preamble, the eNodeB may not be able to schedule the RAR messages on the PDSCH due to other pending higher priority activities such as eNodeB paging. The mobile device may re-initiate the RACH procedure if no RAR message is received within a configured window. However, unless the other higher priority activities at the eNodeB have ceased or been completed, re-initiating of the RACH procedure will likely fail again, and may overload the system.
Even if the RACH procedure is successful, i.e., the mobile device receives the RAR message, problems may occur during the RRC connection request procedure. For example, the mobile device may not get any response from the eNodeB within timer T300 in which timer T300 is a predefined length of time that the mobile device will wait to receive the response after transmitting the RRC connection request. In particular, the eNodeB does not transmit the RRC connection setup message within timer T300 due to some other higher priority activity occurring at the eNodeB. Moreover, the eNodeB may reject the RRC connection request message, i.e., admission control may not accept the RRC connection request. In particular, the eNodeB may transmit a RRC connection rejection message during timer T302 in which timer T302 is a predefined length of time that mobile device will wait until retransmission by the mobile device. Mobile device may re-initiate the RACH procedure after expiration of timer T302. For example, the admission control may reject the RRC connection request due to radio link failure (RLF), among other reasons. However, the re-initiated RACH procedure may continue to fail due to RLF, thereby likely overloading the system, i.e., the mobile device continues to re-initiate the RACH procedure.
Moreover, the mobile device may initiate the RACH procedure after being disconnected while in the RRC_connected state, i.e., to reconnect. For example, the mobile device may be disconnected because the mobile device was not granted uplink (UL) resources due to a lack of UL resources and/or no priority on downlink (DL) scheduling. The mobile device may consider the lack of UL grant and no priority on downlink scheduling as RLF, and may re-initiate the RACH procedure. Moreover, expiration of timers such as T304 may cause mobile device to initiate the RACH procedure in which timer T304 is a predefined length of time for completing mobile device handover. However, re-initiating the RACH procedure does not account for the problem that caused the disconnection, i.e., the mobile device continues trying to re-connect via the same RACH procedure, thereby likely creating additional problems at the eNodeB such as reaching maximum capacity. Moreover, re-connection may occur due to problems with timing synchronization, i.e., loss of the timing alignment synchronization. In other words, even after the mobile device is connected, mobile device may still initiate the RACH procedure while in the RRC_connected state.
Known methods for addressing RACH procedure re-initiation include triggering the back-off indication bit in the RAR message to cause all mobile devices to delay transmission of all RA preamble messages to the eNodeB. However, using the back-off indication bit will not work if the eNodeB is unable to first process the RA preamble message, i.e., is unable to transmitted the RAR message. Moreover, such a brute force solution does not differentiate between services. For example, the mobile device may not be able to initiate a 911 call without having to observe the back-off indication bit. Also, using the back off indication bit for all mobile devices does not differentiate between mobile device states such as idle or connected states.
Another known solution is the use of timer T302 in which the mobile device is prevented from sending RA preamble messages until the expiration of the T302 timer, then mobile device may initiate the RACH procedure. However, the mobile device will be informed by the eNodeB only when timer 302 expires such that the mobile device may initiate RACH procedures again. Such a solution does not help reduce RACH overload because mobile devices will still be able to initiate RACH procedures after the timer.
Yet another known solution is the use of an access class barring facility that includes barring parameters that are preset by the operator in a wideband code division multiple access (WCDMA) based network. For example, all mobile devices may operate according to the barring parameters in a WCDMA based network. However, the barring parameters are not adaptable according to the level of access channel overload, i.e., any detected overload, however minimal, will result in the all mobile devices operating according to the same barring parameters.
Accordingly, it is desirable to have a device, system and method that allows for adaptive overload control of the access channel.